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DEVICE IMPLEMENTATION GUIDELINES 
















Introduction 


The following paragraphs develop guidelines for Implementing new devices 
for 2-D GCS. Included will be the definition of device-dependent Graphics 
Status Area Initialization values, functional specifications for each of the 
2-D GCS device-dependent routines, a discussion of factors Involved In 
supporting Intelligent refresh devices, and a description of phased sequence 
for lmplementating new devices. 







Graphics Status Area Initializations 


In this section, each of the device-dependent elements of the Graphics 

Status Area (GSA) will be listed along with the procedures required to 

calculate the value, if appropriate. 

KBEAMX Logical pen x-position in raster units. Default position is 
lower left corner of largest square on the plotting surface. 

If the screen is rectangular, the square is right- or bottom- 
justified. 

KBEAMY Logical pen y-position in raster units. Default position is 

lower left corner of largest square on the plotting surface. If 
the screen is rectangular, the square is right- or bottom-justified. 

TRSVX Ratio of screen to virtual units in x-dlrection. Default is the 
width of the UDAREA in raster units divided by the width of the 
UWINDO (100.). 

TRSVY Ratio of screen to virtual units in y-dlrectlon. Default is the 
height of the UDAREA in raster units divided by the height of 
the UWINDO(100.). 

KMINSX Minimum X screen window (UDAREA) boundary in raster units. Default 
is the same as KBEAMX. 

KMAXSX Maximum X screen window (UDAREA) boundary in radter units. Default 
is the maximum address in the x-direction. 

KMINSY Minimum Y screen window (UDAREA) boundary in raster units. Default 
is same as KBEAMY. 

KMAXSY Maximum Y screen window (UDAREA) boundary in raster units. Default 
is the address of top boundary of largest square on plotting surface 
whichever is less. 

KCOLOR Color or greyscale switch. Default is the actual color produced by 
the plot head when the device is initialized. 

KHORSZ Horizontal, hardware character position size in raster units. Default 
is the width of the smallest size character position. 

KVERSZ Vertical hardware character position size in raster units. Default 
is the height of the smallest character position. 

KLMRGN Left alphanumeric margin boundary in raster units. Default is 
normally zero (minimum plotting surface address in x-directlon). 

KRMRGN Right alphanumeric margin boundary in raster units. Default is 
the maximum plotting surface address in y-dlrectlon. 

KTMRGN Top alphanumeric margin boundary in raster units. Default is 
the maximum plotting surface address in y-dlrection. 











KBMRGN Bottom alphanumeric margin boundary in raster units. Default 

is normally zero (minimum plotting surface address in y-direction). 

KGIN Graphics input dcivice selector. Default is the primary graphics 
input device on the display. 

KMINDX Minimum x-address of display surface in raster units. Default 
is zero. 

KMAXDX Maximum x-address of display surface in raster units. Default 
for devices with variable size plotting surface is largest 
square using normal plotting medium. 

KMINDY Minimum y-address of display surface in raster units. Default is 
zero. 

KMAXDY Maximum y-address of display surface in raster units. Default 

for devices with variable size plotting surface is largest square 
using normal plotting medium. 

TRASTX X-resolution in raster units per inch. Default is KMAXDX divided 
by width of plotting surface in inches. 

TRASTY Y-resolution in raster units per inch. Default is KMAXDY divided 
by height of plotting surface in inches. 

KTYMNU Device type for menu generation. Possible values are: Graphics 
device * 1, Alphanumeric device » 2, Batch device » 3. 

KILS ILS device indicator. Possible values are: Intelligent device * 1, 
Unintelligent device * 0. 

KBAUDR Speed of communication line in characters per second. Default is 
usual speed for device. 

KPCHAR X,Y component buffer. Used by GCSPEN as a work area. Default 
should reflect an impossible or unusable value. 

KPREVC Color which terminal is currently generating. Default is the same 
as KCOLOR. 
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UDIMEN (XMAX,YMAX) 


XMAX Defines the maximum extent of a variable display surface dimension 
along the x-axis. 

YHAX Defines the maximum extent of a variable display surface dimensions 
along the y-axis * 


Comments 


This routine is used to set the size of a variable plotting surface 
such as CALCOMP drum plotters. The value contained in each dimension 
which varies is converted from current device units to raster units 
and tested for legal value. If the new dimension is legal for the 
device, the resulting raster unit value is stored in KMAXDX or KMAXDY as 
appropriate. 

For display-devices with a fixed size plotting surface, this routine 
need only set the UDAREA boundaries to the entire plotting surface. This 
should be done if the plotting surface is variable also. 

This routine is not implementable at the display-device. 








UERASE 


Connnents 


This routine provides a clean plotting surface by either erasing 
the plotting surface or advancing the plotting medium to an unused frame. 
In implementing this routine, care must be taken to insure that the 
current pen/beam position remains unaltered but in the new plotting 
surface. This may require a call to the GCSPEN routine after the 
"erase" occurs. 

This function may be supported at the display-device. In this <mse, 
only an indication that the erase must occur need be transmitted to the 
device. The beam position must still be insured. 






URESET 


Comments 


This routine returns the Graphics Status Area to its initial condition. 
Aside from setting the device-dependent GSA elements to agree with those 
in the BLOCK DATA subroutine for this device before compilation, no 
further modifications are required. 

This routine can not be supported at the display-device. 





UWAIT(TIME) 


TIME Indicates the amount of time which GCS will wait before sending 
further commands to the display. 

Comments 

This routine is usually Implemented by sending a sufficient number 
of null-operation control characters across the communication line to 
cause the required delay. 

The KBAUDR 6SA element specifies the line speed in characters per 
second. 

For batch devices, this routine is a null operation. 

This routine can not be supported at the display. 
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GCSALF(ICHAR) 


ICHAR Is one ASCII character, right-justified, zero-fill. 

Comments 

This routine causes one hardware character to be displayed after 
the terminal is placed in alpha mode and KKMODE is set to reflect alpha 
mode. If a hardware character generator is not available and if the 
device is not intelligent, a device-independent hardware character 
simulator version of GCSALF is available. If a hardware character 
generator or simulator is available at the display, the printable 
ASCII character is simply sent to the display. Only displayable ASCII 
characters are output from this routine. The receipt of control 
characters implies that the terminal be placed in alpha mode and that the 
character size be updated if necessary. Two control characters have special 
extra meaning for intelligent displays. A value of OOlg indicates start 
of alpha string and 002g indicates end of alpha string. This*allows strings 
of characters to be processed as one primitive operation.at the display. 

To update the character size, on input the value of KSIZEF is compared 
to the value of KPREVS. If their values agree, then no size change need be 
processed. If their values disagree, the value of KSIZEF is stored in 
KPREVS and the new sizes are stored In KHORSZ and KVERSZ. 

This function may be supported at an intelligent display-device either 
by sending single characters or by using OOlg and 002g brackets to send 
character strings. 








GCSARC(X, Y,ANGLE.RADIUS»ICHECK) 


X,Y Are the coordinates of the center of the circle defined by the 

arc. 

ANGLE Indicates the angle the arc will subtend and the direction of 
travel of the arc. A positive angle is counterclockwise; 
a negative angle is clockwise. 

RADIUS Specifies the radius of the circle. 

ICHECK Is set to 1 if the arc is not drawn by GCSARC. It is set to 
zero otherwise. 


Comments 


If hardware arc generation is available and if the arc can be drawn 
and does not intersect the window, the flag is set to zero and the 
appropriate instruction is sent to the display. If, for some reason, 
the arc can not be drawn at the display, the flag is set to 1. Reasons 
which might apply are lack of an arc generation facility at the device 
or intersection of the arc with the window. 

This function may be supported at the device if the arc to be 
drawn does not intersect the window. If it does intersect the window, 

GCSARC may calculate the visible arc segments and issue several instructions 
to draw each segment. However, the instructions to perform these calculations 
are somewhat complex and it is usually left to UARC to draw the desired arc. 






GCSBPK (IX,IY, ICHAR) 


IX,IY Is the location to be marked by the character or dot. 

ICHAR Is the ASCII code fill character for the designated raster 
position. 


Comments 


This routine maintains the internal raster buffer for raster devices 
such as line printers and alphanumeric terminals without cursor addressing. 
The buffer is a FORTRAN Common Area GCSBUF which contains storage for the 
entire frame or a page of the frame. The IX,IY values are mapped into a 
buffer character position and the character (after translation into 
internal computer code) is Inserted in this position. 

This routine only does packing. Flushing of the buffer is handled 
by GCSPEN. 

This routine may be supported at the display-device if an intelligent 
raster-scan terminal or an unintelligent raster-scan terminal with local 
storage is being implemented. In this case, this routine should be 
eliminated and GCSPEN should send the packing request ditectly to the 
terminal• 









GCSDSH(IX.IY) 

IX,IY Raster unit location of the end of the dashed line. 

Comments 

This routine draws a dashed line based on the current dash 
specification contained in the KDASHT GSA variable. KDASHT values 
between one and nine indicate selection of various hardware dash modes. 

In none are available, a standard dash is simulated. A value of nine refers 
to hardware dotted line mode if available. 

If a hardware dash is available, a call is made to GCSPEN with an opcode 
value of four to draw the line. If a hardware dash is not available or 
not requested, the desired dash sequence is simulated by calling GCSPEN to 
draw alternating solid and invisible lines. 

This function is not supportable at the display-device. 
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GCSBEG 

Comments 

This routine performs any initialization functions required by the 
display. For intelligent devices, it may pass the initialization request 
to the device. 





GCSEND 

Comments 

This routine performs any termination functions required by the 
display-device. For Intelligent devices. It may pass the termination 
request to the device. 







p 


GCSFRA(INDEX.OPCODE) 

INDEX Is Che numeric Identifier for the frame. 

OPCODE Is the action to be performed related to the designated frame. 

Comments 

This routine processes the frame manipulation function requests of 
"open", "close", "show", and "unshow". Since these operations are 
currently supported only in an intelligent display, this function becomes 
a null routine for unintelligent devices. The function of this routine 
is primarily to reformat the requested operation as necessary and transmit 
it to the display. 

This is an interface routine which communicates with a program executing 
in the display-device general processor if the display is intelligent. 
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GCSIN(ICOUNT.IBUFR) 


ICOUNT Indicates the upper limit of the number of ASCII characters to 

be received as input. 

IBUFR Is a buffer in which the ASCII characters will be placed right- 
justified, zero-fill. 

Comments 

This is primarily an interface routine to the operating system 
function which actually obtains the character. If less than ICOUNT 
characters are received, the remaining buffer positions should be zeroed. 

This function can not be supported at the display since it is really 
not device-dependent but operating system dependent. However, to Insure 
correct linkage editing on all operating systems, it is grouped with 
the device-dependent routines. 

For batch devices, this routine Issues an error message and returns 


null characters. 









GCSINN(ICOUNT.ISTRING) 


ICOUNT Indicates the number of ASCII characters to be read from the 
terminal. 

ISTRNG Is a buffer into which the ICOUNT characters will be placed. 

Comments 


This routine accepts strings of ASCII characters from the terminal. 
Prior to issuing an input operation using GCSIN, the terminal is placed 
in the appropriate mode to activate the keyboard input. If ICOUNT is 
less than or equal to zero, no input operation takes place. 

This function can not be supported at the display. 








GCSOUT(ICOUNT,IBUFR.IRES?) 


ICOUNT Indicates the number of ASCII characters to be transmitted 
to the display. 

IBUFR Is the buffer containing ICOUNT ASCII characters right-justified, 
zero-fill. 

IRES? Is a count indicating the number of acknowledgement characters 
required from the terminal. This is only used for supporting 
intelligent devices. 

Comments 

This is the interface routine between GCS and the operating system 
routine which sends characters to the terminal. It is called by all GCS 
routines which need to transmit to the display. If ICOUNT “ 0, the 
operating system is requested to flush any Internal buffers. 

This routine can not be supported at the display. 

For batch devices, this routine performs only one function: It 
intercepts GCS error messages and displays them on the system-print file. 

For supporting intelligent displays, the IRES? arguments can be 
used to request an acknowledgement from the device before further characters 
are sent. It is usually used when sending functions which require 
considerable execution time at the display. 
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GCSPEN (IX,IY,IPEN) 

IX,IY Is the end point of the line to be drawn in raster units. 

IPEN Indicates the operation to be performed. Zero specifies a move; 

one specifies a solid line; two specifies a point; three specifies 
a buffer flush request; and four specifies a dashed line. 

Comments 

This routine is the basic line drawing routine for each device. Several 
variables have been set aside in the GSA for use by this routine. The 
array KPCHAR is for use as an internal work space and usually is where the 
command to be sent to the display is constructed. KPREVX and KPREVY are 
updated with the value IX and IY to always point to the current beam 
position when GCSPEN terminates. GCSPEN may also need to fetch additional 
information to insert intensity, blink, or other information into the command. 
The variable KKMODE is updated to reflect any mode changes initiated by 
GCSPEN. If the display-device is such that a separate Invisible line mode 
is used, GCSPEN will set KMOVEF to one whenever he will exit with the 
display-device primed for a blank line. Otherwise, KMOVEF is set to zero. 

This routine can be supported at an intelligent display-device. If 
such is to be the case, GCSPEN must still process buffer flush requests, 
must check for redundant "moves" to the current beam position, must maintain 
KKMODE settings as necessary, and reformat the line drawing instruction to 
be sent to the display. 

For terminal devices, output from GCSPEN is sent through GCSOUT. For 
batch devices, output is written on the appropriate files either directly or 
using a device-specific support package. 

Note: GCS assumes that the plotting surface is addressed from zero to 
some maximum number. If the actual address range contains negative numbers, 
it is the responsibility of GCSPEN to add in the appropriate displacement 
before building the display processor commands. 
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GCSSET(OPTION) 


OPTION Is a standard form (four-character, left-justified, blank-fill) 
USET option passed from USET. 


Comments 


This routine performs hardware-supported mode setting. All USET 
requests are passed to GCSSET. If a particular option requires Immediate 
mode setting at the display, it is recognized by GCSSET and the 
appropriate request is sent to the display. 

This function can not be supported solely at the display. However, 
intelligent displays which support some mode setting will require a parallel 
routine to receive the requests sent by GCSSET. 
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GCSWHR(IX.IY.IC) 


IX,IY Will contain the raster unit coordinates of the input cursor 
position. 

IC Is a mode, status, or option character obtained during the input 

operation. If IC * 0 upon entry to GCSWHR, only the character is 
requested. 


Comments 

This routine performs "positioning"-type input operations from the 
input device specified by GSA variable KGIN or the closest available 
equivalent. Whatever the form of the input coordinates when received, 
they must be converted to standard raster unit format. The mode, status, 
or option character is returned as received to the calling routine. 

This routine can not be supported at the display, but may require 
a parallel function to execute in an intelligent device. 






Guidelines for Intelligent Devices 

Display-devices which have computing power of their own may be termed 
intelligent. Appropriate use of the intelligence can greatly increase 
the capabilities of the entire system. Most such display-devices have 
a refresh capability. Thus much of the capacity of the general processor 
of the capability of the general processor of the device is involved with 
display list management. 

In GCS, a display li'st management facility has been provided to support 
dynamic pictures in a device-independent manner to the extent that the 
program will execute even while using dynamic instructions on a non-refresh 
device. This is the framing facility. A more conmonly used name for this 
feature is transformed, segmented, unstructed display list. Four functions 
are suppported for these frames: open (UFRAME), close (UFREND), make visible 
(USHOW), and make invisible (UNSHOW). These four routines all call the device¬ 
dependent routine GCSFRA with the number of the frame to initiate the 
requested operation. GCSFRA passes these requests to the intelligent terminal. 
If no named frame is open, an unnamed frame is maintained which is always 
visible. 

In the display, an open operation starts up a new segment for the 
Indicated frame number. If a segment for that frame is already being displayed, 
a double buffering takes place which continues showing the elder of the two 
frames with identical numbers until the newer frame definition is complete 
(indicated by receiving a close (UFREND) command). At this time, the elder 
frame is discarded and the newer frame is displayed. A frame may be 
constructed either visibly or invisibly. If a frame is constructed visibly, 
it will be shown when completed. It can then be made invisible by executing 
an UNSHOW conmand. If a frame is constructed invisibly, it will not be 
displayed until a USHOW command is received. Subsequent USHOW and UNSHOW 
commands can turn off and on defined frames as requested. 

The logical organization of the display list is as above. The actual 
physical organization and technique of memory management will depend on the 
particular display-device. Some will more naturally use a paging memory 
management scheme; others may use some type of linked list. 

In sddltlon to display list management routines, the Intelligent device 
genersl processor will also need to interfsee avsilable hardware functions 
with the device-dependent routines of GCS and to provide simulators as desired 
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for device-dependent functions not available in the particular hardware 
under consideration. 

In designing the format in which the device-dependent GCS routines 
communicate'with the dieplay-device, it is wise to select an encoding scheme 
that does not violate ASCII coding conventions. This requires that only 
seven bits be used as data and the parity-bit reserved for parity or marking 
even if the particular operating system does not require it. Following 
this procedure will allow connection of the terminal with the host-computer 
over standard communication lines without special communications software. 
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GCS is a modular system. Since many of the devices supported by GCS 
are relatively unsophisticated, many of the GCS device-dependent libraries 
contain simulators for many of the hardware functions. By using these 
simulators, it is possible to shorten the initial implementation time for 
new devices allowing later replacement of the simulators as time permits. 

The following scheme for phased implementation of new devices has been 
designed to maximize the benefits mentioned above. 

Phase 1: Identify the required initialization values for each device¬ 
dependent GSA variable and insert them in the Block Data and 
URESET subroutines. 

Phase 2: For intelligent devices, design the communication data structure 
to be used between the device-dependent GCS routines and the 
program executing in the display-device. This program should be 
developed in parallel to the device-dependent GCS routines in the 
regaining phases if not already available. 

Phase 3: Implement the GCSBEG, GCSSET, and GCSEND functions if necessary. 

Phase 4: Implement the UERASE and GCEPEN routines. The GCSOUT routine can 

usually be used without modification from one of the other libraries. 
Simulators or null routines can be used for the remaining functions. 

Phase 5: Implement the GCSALF routines if a hardware character generator 

is available. This would replace the hardware character simulator. 

Phase 6: Implement the GCSFRA routine, if the terminal is intelligent. If 
not, the null version of the GCSFRA routine is appropriate. 

Phase 7: Implement GCSIN, GCSINN, and GCSWHR functions if the device is 
interactive. These would then replace the null routines which 
probably were used until this phase. 

Phase 8: Implement all other functions which do not yet support the capabilities 
of the device. 

By following the sequence above, experience has shown that implementation of 
new devices should proceed smoothly. 
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